REMARKS 



Claims 1-51 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Section 102(e) Rejection : 

The Office Action rejected claims 1, 18 and 35 under 35 U.S.C. § 102(e) as being 
anticipated by He et al. (U.S. Patent 6,088,451) (hereinafter "He"). Applicants 
respectfully traverse this rejection in light of the following remarks. 

Regarding claim 1, applicants respectfully disagree with the Examiner and submit 
that He fails to teach a client using a capability credential to request an access interface 
document to access a service, the client receiving the access interface document , wherein 
the access interface document comprises an interface for accessing only a portion of the 
service's capabilities , and the client using the interface from the access interface 
document to access a capability from the portion of the service's capabilities. He 
presents a system for securing access to network elements by user elements (He, 
Abstract). He does not disclose anything regarding an access interface document 
comprising an interface to accessing only a portion of a service's capabilities, as the 
Examiner contends. Instead, He teaches a hierarchy of tickets that are used for access 
control. He also teaches controlling access to network elements through the use of an 
authentication server, a credential server and a network element access server (He, 
column 2, lines 12-16). He is not concerned with access interface documents by which a 
client accesses a service. The access control credentials and tickets, such as He's general 
and session tickets, are used only for access control^ not as access interface documents. 

He fails to teach a client using the capability credential to request an access 
interface document to access the first service. The Examiner cites column 20, line 14 
through colunm 21, line 22 of He, however applicants note that this passage describes 
He's ticket system in which a user presents a general ticket obtained from a credential 
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server to a network element access server to receive a session ticket (He, column 20, lines 
16 -19). Thus, He teaches that a general ticket, provided to a user during login, is used to 
obtain a session ticket that includes a unique session encryption key (He, column 2, lines 
36-51). He's session ticket is certainly not an access interface document and obtaining 
such a session ticket cannot be considered requesting an access interface document. 
Nowhere does He disclose anything regarding a client using a capability credential to 
request an access interface document to access the first server. No credential or ticket in 
He is an access interface document comprising an interface for accessing only a portion 
of the first service's capabilities . Li fact. He teaches explicitly that a session ticket "is 
encrypted using a key derived from the password of the selected network element so that 
only the selected network element can verify the session ticket" (He, column 2, lines 51- 
55). He's session ticket is clearly an authentication credential used by network elements 
to verify communications from the user and just as clearly does not include an access 
interface document. 

Further regarding claim 1, applicants submit that He also fails to teach the client 
receivins the access interface document , wherein the access interface document 
comprises an interface for accessing only said portion of the first service's capabilities. 
The Examiner holds that He discloses this by teaching how a user may gain access to pull 
down menus in order to choose a specific network element with which to communicate. 
However, the pull-down menus of He are not access interface documents, but are merely 
a mechanism by which a user may select a particular network element to communicate 
with. Applicants submit that the Examiner has not shown any teaching in He that 
discloses the receiving of an access interface document. The Examiner contends that 
when a user of He's system is given access to such pull dovm menus to identify network 
elements, a client is receiving an access interface document that comprises an interface 
for accessing only a portion of a service's capabilities. He, however, teaches that the user 
may use the pull down menus to make an access request for a particular network element 
(He, column 26, lines 60-62). Allowing a user to access pull down menus to select a 
desired network element does not constitute receiving an access interface document. The 
pull-down menus of He only allow a user to select a particular network element and do 
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not comprise an interface for accessing only a portion of a service's capabilities, as the 
Examiner suggests. He uses pull-down menus only in their traditional use as user 
interface elements allowing users to select a specific entry. No one of ordinary skill in 
the art would interpret such pull down menus as access interface documents. He does not 
mention anything about receiving an access interface document, nor about the use of pull 
down menus involving any access interface document comprising an interface for 
accessing a portion of a service's capabilities. 

The Examiner also asserts that a user (in He's system) using a pull dovm menu to 
make an access request corresponds to a client using the interface from the access 
interface document to access a capability from said portion of the first service's 
capabilities. Applicants disagree with the Examiner's interpretation of He. He teaches 
that once the user selects a desired network element through a pull down menu, the user 
element local access control system sends an access request to the network security 
server that "returns a session ticket to the user element for communicating with the 
selected network element" (He, column 27, lines 40-47). Thus, the Examiner's 
interpretation of He is clearly incorrect. The Examiner holds that obtaining a session 
ticket equates to requesting an access interface document and that selecting a network 
element in order to obtain a session ticket corresponds to using the received access 
interface document. For the Examiner's interpretation to be correct, a user would have to 
use a received access interface document (by selecting a network element through a pull 
down menu, according to the Examiner) before actually requesting the access interface 
document (by obtaining the session ticket, in the Examiner's interpretation). Such an 
interpretation cannot be correct. 

Further, He describes how a session ticket includes a unique session encryption 
key. Thus, when the user selects a network element, the user is actually performing an 
authentication function by presenting a general ticket in order to obtain a session 
encryption key with the session ticket. Hence, He teaches that a user selects a specific 
network element from a pull down menu to request a session ticket and encryption key to 
allow fixture access to the network element and is clearly not teaching that such an action 
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includes using an interface from an access interface document to access a capability from 
a portion of a service's capabilities. 

Applicants respectfully remind the Examiner that anticipation requires the 
presence in a single prior art reference disclosure of each and every element of the 
claimed invention, arranged as in the claim . M.P.E.P 2131; Lindemann Maschinenfabrik 
GmbH V. American Hoist & Derrick Co,, 111 USPQ 481, 485 (Fed. Cir. 1984). The 
identical invention must be shown in as complete detail as is contained in the claims. 
Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

In light of the above remarks, Applicant submits that the rejection of claim 1 is 
not supported by the teachings of the cited art and withdrawal thereof is respectfiiUy 
requested. Similar arguments apply in regard to independent claims 18 and 35. 

Section 103 (a) Rejection : 

The Office Action rejected claims 2-17, 19-34 and 36-51 under 35 U.S.C. § 
103(a) as being unpatentable over He in view of Pulliam et al. (U.S. Patent 6,609,108) 
(hereinafter "Pulliam"). 

Regarding claim 2, He in view of Pulliam fails to teach wherein using a capability 
credential to request an access interface document comprises sending an advertisement 
request message in a data representation language , wherein the advertisement request 
message includes the capabihty credential, as asserted by the Examiner. The Examiner 
recognizes that He fails to teach sending an advertisement request message in a data 
representation language, and relies upon Pulliam to disclose this ftinctionality. PulUam 
teaches an online shopping communication schema for communication online shopping 
orders such as vehicle orders (Pulliam, Abstract) and has nothing to do with a client 
requesting an interface document comprising an interface usable by the client to access 
only a portion of a service's capabilities. 
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PuUiam teaches that a cUent may request a Ust of identifier and value pairs for a 
number of criteria and may use the retumed values to populate pull-down lists of 
available automobile makes and models (PuUiam, column 13, lines 31-37). The 
Examiner holds that such pull-down lists are an access interface document to access the 
available makes and models. Applicants disagree. PuUiam never mentions anything 
regarding an access interface document, nor about using such pull-down lists as an access 
interface document that comprises an interface for accessing a portion of a service's 
capabilities . In contrast, PuUiam teaches that the client uses the pull-down lists and a 
user's selections among the pull-down lists to compile an XML message "that requests a 
list of matching vehicles in inventory database 612" (PuUiam, column 13, lines 37-49). 
Thus, rather than being an access interface document as the Examiner contends, the pull- 
down lists, and the data that make up such lists, are clearly just search criteria, and 
therefore just data, to be sent as part of a database search request. 

Additionally, PuUiam fails to disclose anything regarding sending an 
advertisement request message. Advertisement request messages are well understood in 
the art and have nothing to do with searching an online automobile database according to 
user specified search criteria. The Examiner's cited passages (PuUiam, column 14, lines 
34-45, and column 15, lines 38-42) refer only to a locate server that uses PKI encrypted 
user credentials to provide access control. Neither of these passage teaches anything 
regarding sending an advertisement request message in a data representation language. 
Even through PuUiam teaches the use of XML to describe the search criteria and the 
corresponding search results (PuUiam, column 13, lines 25-29), PuUiam fails to teach 
sending an advertisement request message in a data representation language. Applicants 
submit that sending an advertisement request message is very different than sending 
search criteria and search result messages in XML. Just because XML is a data 
representation language, does not mean that using XML for search criteria or search 
result messages corresponds to sending an advertisement request message. 

Furthermore, applicants submit that the proposed combination of He and PuUiam, 
as suggested by the Examiner, would not result in any system that includes sending an 
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advertisement request message in a data representation language as part of using a 
capability credential to request an access interface document. Instead, such a 
combination would result in an online automobile search system that uses He's general 
and session security tickets to obtain authorization for user searches of available vehicles. 
Since both He and Pulliam fail to teach anything regarding using a capability credential 
to request an access interface and both also fail to disclose sending an advertisement 
request message in a data representation language, the proposed combination of He and 
Pulliam would not include such features. 

In the Response to Arguments section of the Office Action, the Examiner states, 
"one cannot show nonobviousness by attacking the references individually where the 
rejections are based on combination of references." However, applicants specifically 
stated, as part of the previous argument, "even if He's system was modified so that a user 
requested a ticket by sending a request message in a data representation language, the 
request would still be for just a ticket, not an interface document comprising an interface 
usable by the client to access only a portion of a service's capabilities" (See Response 
dated June 28, 2004, page 14, lines 10-13). The examiner has failed to provide any 
specific response to applicants' previous arguments in regard to claim 2. 

Thus, the rejection of claim 2 is not supported by the teachings of the cited art and 
withdrawal thereof is respectfully requested. Similar arguments apply in regard to claims 
19 and 36. 

Regarding claim 4, He in view of Pulliam does not teach generating a custom 
advertisement in response to receiving the advertisement request message. Additionally, 
He in view of Pulliam fails to disclose that a custom advertisement is generated according 
to the portion of the service's capabilities that the capability credential indicates the client 
is allowed to access, and sending an advertisement request response message to the 
client, wherein the advertisement request response message includes the custom 
advertisement as the access interface document. The Examiner's rejection states, 
"generating pull-down menus to identify those capabilities to which the client is allowed 
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to access" (emphasis added) citing He, column 26, lines 58-65 and PuUiam, column 13, 
lines 34-40). However, the pull-down menus in He and Pulliam referred to by the 
Examiner have nothing to do with generating a custom advertisement as the access 
interface document according to the portion of the service's capabilities that the 
capability credential indicates the client is allowed to access. He's pull down menus 
"identify those network elements to which [the user] is allowed access." The cited 
section of Pulliam pertains to "pull-down lists of available makes and models" which 
may be used to select "preferences" for "matching vehicles" as described above regarding 
claim 2. Pulliam' s teachings have nothing to do with generating a custom advertisement 
according to a portion of a service's capabilities. 

Furthermore, the Examiner refers to He's and Pulliam' s pull-down menus as 
identifying capabilities. He, however, does not teach using pull-down menus to identify 
capabilities, but instead uses pull-down menus to identify those specific network 
elements with which a user may communicate (He, column 26, lines 58-65), not any 
particular capabilities or portions of the capabilities of a service that a user may access. 
Similarly, Pulliam never describes pull-down menus as identifying service capabiKties. 
Instead, Pulliam uses pull-down lists as one example of collected search criteria fi"om a 
user (Pulliam, column 13, lines 34-37). The Examiner is clearly applying his own 
speculation to the teachings of He and Pulliam. 

Applicants submit that He and Pulliam, both singly and in combination, fail to 
teach generating and sending, in response to receiving the advertisement request 
message, an advertisement request response message which includes a custom 
advertisement generated according to a portion of a service's capabilities that a client is 
allowed to access as indicated by a capability credential. Therefore, the rejection of 
claim 4 is not supported by the teachings of the cited art and withdrawal thereof is 
respectfully requested. 

Regarding claim 5, He in view of Pulliam does not teach or suggest a custom 
advertisement that specifies an XML schema defining messages to be sent by the client to 
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the service and messages to be sent from the service to the cUent to use the portion of the 
service's capabiUties. The portions cited by the Examiner (PuUiam, column 15, lines 39- 
43 and column 16, lines 40-50) refer to the use of XML "to support application-to- 
application data exchange formats." In Pulliam, XML is used to describe the data 
content of messages, not to define the messages themselves. XML, as used by Pulliam 
does not define messages to be sent by the client to the service nor messages to be sent 
from the service to the client to use the portion of the service's capabilities. 

Li response to the above argument, the Examiner cites the same portions of 
Pulliam (column 15, lines 39-43, and column 16, lines 40-50) discussed above and refers 
to Pulliam' s use of XML to send various messages. Hov^ever, Pulliam does not mention 
an XML schema defining messages to be sent by the client to the service, nor does he 
describe messages to be sent from the service to the client. Applicants submit that 
Pulliam' s use of XML message to exchange data between applications does not include 
such an XML schema. In fact, PulKam himself describes the format of the messages used 
in his system (PuUiam, column 16, line 45 - column 17, line 29). Hence, rather than 
teaching a custom advertisement that specifies an XML schema defining messages, 
Pulliam describes the specific XML tags and message formats used in his system. 

The rejection of claim 5 is fiirther improper because the Examiner has not 
explained how Pulliam suggests modifying He's system. The use of an XML schema in 
Pulliam to describe data to be exchanged in online shopping does not have any relevance 
to the access control ticket requests in He. Therefore, the combination of references is 
improper. 

In light of the above remarks, applicants submit that the rejection of claim 5 is not 
supported by the cited prior art and removal thereof is respectfiilly requested. Similar 
arguments apply in regard to claims 22 and 39. 

Regarding claim 6, He in view of Pulliam fails to teach the client receiving a 
protected advertisement for the first service, wherein the protected advertisement 



09/653 .6 1 0 (5 1 8 1 -70500/P520 1 ) 



9 



Meyertons, Hood, ICivlin, Kowert & Goetzel, P.C. 



provides an address to request said security credential. The Examiner contends that He 
teaches that a user authenticates to the network and "obtains an authentication ticket that 
contains, or redirects the user to, the address of credential server 204", citing column 17, 
lines 55-67 and column 18, lines 1-23 of He. However, applicants note that neither of the 
cited passages describe anything about an authentication ticket containing or redirecting 
the user to the address of credential server 204. Instead, He teaches that a user sends a 
request message to authentication server 202 for user authentication and further teaches 
that authentication server 202 sends "a general ticket for the user to communicate with 
the credential server 204" (He, column 17, line 66 - column 18, line 2). Nowhere does 
He describe this general ticket as containing, or redirecting the user to, the address of 
credential server 204. In fact, He teaches, "the content of the ticket is not able to be 
observed and cannot be changed by the user, thanks to the encryption/decryption ... 
applied to the ticket" (emphasis added) (He, column 18, lines 13-17). Such a ticket 
(whose content cannot be examined) carmot contain, or redirect the user to, the address of 
the credential server as asserted by the Examiner. The Examiner is clearly applying his 
own speculation into the teaching of He regarding the contents of the general 
authentication ticket. 

Thus, the rejection of claim 6 is not supported by the cited prior art and removal 
thereof is respectfully requested. Similar arguments apply in regard to claims 23 and 40. 

Applicants also assert that the rejections of numerous ones of the dependent 
claims are further unsupported by the cited art. However, since the rejections of each of 
the independent claims have been shown to be improper, a further discussion of the 
rejections of the dependent claims is not necessary at this time. 

Information Disclosure Statements : 

Applicants note that the Examiner has not returned the signed and initialed copies 
of the forms PTO-1449 fi-om the information disclosure statements submitted on July 19, 
2001 and October 9, 2003, respectively. Applicants request the Examiner to carefully 
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consider the listed references and return copies of the signed and initialed Forms PTO- 
1449 from both of these statements. Copies of the previously submitted forms PTO-1449 
from these statements are included herewith for the Examiner's convenience. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
70500/RCK. 

Also enclosed herewith are the following items: 
^ Return Receipt Postcard 
I I Petition for Extension of Time 
I I Notice of Change of Address 

1^ Copies of previously submitted forms PTO-1449 from the information disclosure 
statements submitted on July 19, 2001 and October 9, 2003, respectively 
□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: October 11. 2004 
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Respectfully submitted. 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



